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Foreword 

-  Notes  - 


Executive  Summary 

-  Notes  (cont.)  - 
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-  Notes  (cont.)  - 


Executive  Summary 

-  Notes  (cont.)  - 


Executive  Summary 

-  Notes  (cont.)  - 


Executive  Summary 

-  Notes  (cont.)  - 


Tasking 


•  Formal  Terms  of  Reference* 

-  What  are  benefits  and  obstacles  to  an  Open  Systems  Process? 

-  What  would  we  have  to  do  to  realize  the  benefits? 

-  New  and  legacy  systems;  not  just  IT 

•  Initial  discussions  with  USD(A&T),  OS-JTF 

-  “DoD  has  been  working  on  Open  Systems  —  this  is  important,  but  we 
haven’t  gotten  our  arms  around  it” 

-  “Need  the  Task  Force  to  recommend  a  conceptual  framework  for 
proceeding” 


This  is  not  an  esoteric  report  about  formal  “Open  Systems”  — 

It  is  about  exploiting  Lessons  Learned  from  the  Open  Systems  experience 
to  achieve  a  major  advance  in  DoD  combat  and  acquisition  effectiveness 
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Conclusions 


•  Open  Systems  Process  is  fundamental  to  many  DoD  priorities  that  are  dependent  upon  a 
process-based  approach 

-  JV  2010  and  Service  equivalents  -  Reduced  cycle  time  and  ownership  costs 

-  Force  modernization  -  Favorable  industrial  base  realignment 

Open  Systems  Process  is  a  Warfighting  and  Title  10  essential  core  value 

•  Forces,  systems,  and  processes  need  to  leverage  change: 

-  Configure  Forces,  systems  and  processes  for  continuous  viability 

-  Achieve  architecture-driven  modularity 

-  Manage  to  the  natural  cycle  rates  of  underlying  components 

•  Open  Systems  Process  is  based  upon  a  hierarchy  of  architectures  and  standards  developed 
with  a  performance-based  collaborative  approach 

•  Unlikely  that  DoD  can  implement  Open  Systems  Process  by  usual  bureaucratic  means 

-  Open  Systems  Process  is  a  cultural  and  budget  challenge—  process  is  within  our  grasp 

-  Requires  support  from  DoD,  Administration,  Hill,  and  Industry 

-  Need  to  reconfigure  Forces,  systems,  and  management  processes 

-  Removing  impediments  is  most  important 

Requires  aggressive  leadership,  SecDef  and  Service  Secretary  championing 
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Conclusions 

-  Notes  (cont.)  - 
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Some  Terms 


•  A  remarkably  small  vocabulary  is  used  with  little  differentiation  to  describe  a 
broad  range  of  concepts,  hindering  critical  thinking  and  effective  communication 

•  For  this  report  we  use  the  following  terms  to  differentiate  key  concepts: 

-  Plug  &  Fight  (Force  Level)  or  Plug  &  Play  (Component  Level):  The  ability  to  readily 
incorporate  functionally  compatible  parts  on  short  notice 

-  Open  Systems  Process  (OS  Process ):  The  process  of  achieving  Plug  &  Fight/Play 

-  Architecture:  The  overall  structure  of  a  solution 

-  Open :  Modular  architectures  with  completely  defined  and  publicly  available  interfaces, 
supported  by  consensus-based  standards 

-  Openness :  The  degree  to  which  an  architecture  or  standard  is  open 

-  COTS:  A  commercial  catalog  item  —  COTS  is  not  necessarily  Open 

-  Practical  Open:  Most  practical  [vs.  most  pure]  Openness 

-  F3I:  Specifying  Form,  Fit,  Function,  and  Interface  (F3I)  to  permit  Plug  &  Fight/Play 
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Why  We  Care 
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Why  Do  We  Care? 


•  Here  is  what  the  leadership  has  said: 

-  JV  2010:  “Applications  of  new  technology  will  transform  the  traditional  functions 
of  maneuver,  strike,  protection,  and  logistics.  These  transformations  will  be  so 
powerful  that  they  become,  in  effect,  new  operational  concepts  ....  These 
operational  concepts  will  provide  our  forces  with  a  new  conceptual  framework.” 

-  Concept  for  Future  Joint  Operations:  “The  key  characteristic  we  seek  for  our 
Armed  Forces  is  the  ability  to  conduct  dominant  operations  across  the  full  range  of 
possible  missions.” 

-  Secretary  Cohen:  “In  March,  I  went  out  to  see  the  U.S.  Army’s  Force  XXI 
experiments  ....  It  was  an  awe-inspiring  demonstration  ....  Force  XXI  is  the 
much-vaunted  Revolution  in  Military  Affairs  made  real ....  I  knew  that  the 
technology  I  was  seeing  was  key  to  U.S.  military  superiority  in  the  future.” 


But  DoD  is  already  on  a  downward  spiral,  even  with  today’s  missions  ... 

It  is  unlikely  that  either  JV2010  or  the  Revolution  in  Military  Affairs  can  occur 
without  a  major  change  in  how  we  configure  our  Forces,  Systems,  and  Processes 
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Why  We  Care 

-  Warfighting  - 


•  Emerging  CONOPS  will  be  pick-up  actions:  collaborative,  quick  responses  to 
uncertain  enemies  in  remote,  poorly  understood  locations  with  little  infrastructure 

-  Ability  to  quickly  integrate  and  execute  will  be  a  core  warfighting  competency 

-  Quick  response  requires  ability  to  constitute,  configure,  and  execute  Forces  on  the  run 

-  Highly  integrated,  mutually  dependent,  joint  operations  with  coalition  Forces 

•  CONOPS  massively  dependent  upon  ready  constitution,  dynamic  collaborative 
planning  and  execution,  and  JV20 10- style  sustainment 

•  Can’t  get  there  from  here  without  a  quantum  increase  in  Plug  &  Fight  capabilities 
across  the  force:  training,  planning,  deployment,  ops,  sustainment,  support 

•  Analogous  to  Reliability  for  the  Air  Force  in  early  ‘80s 


“The  high  availability  of  our  front  line  aircraft  was  a  major  factor  in  the  outstanding  Air  Force 
performance  in  Desert  Storm!  Plug  &  Fight  has  a  similar  potential  for  quantum  improvement 

and  could  be  our  next  great  leap  forward” 

General  (Ret)  Larry  Welch,  former  Chief  of  Staff,  U.S.  Air  Force 
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Why  We  Care 

-  Title  10,  Training  and  Equipping  the  Force  - 


•  Acquisition  and  Support 

-  Current  processes  are  based  on  a  world  which  no  longer  exists 

•  Requirements  and  technology  evolved  slowly  in  most  areas 

•  Parts  presumed  to  be  available  at  reasonable  costs  over  long  periods 

•  Could  repair,  rebuild,  or  replace  from  detailed  drawings,  part  lists 

-  Although  these  conditions  no  longer  exist,  our  processes  haven’t  changed 
accordingly 

-  Our  acquisition  and  support  centers  are  in  extremis 

•  Train- As- You-Fight 

-  If  training  with  component,  joint,  and  coalition  Forces  is  to  be  effective,  Forces 
must  be  much  more  Plug  &  Fight-capable  than  they  are  today 
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Why  We  Care 

-  Conclusions  - 

•  The  world  has  changed  .... 

-  Operational  demands  are  up,  not  down 

-  Investment  and  O&S  accounts  likely  to  remain  at  reduced  levels 

-  Changes  in  industrial  base  are  leaving  DoD  behind 

•  DoD  can  neither  Equip,  Train,  Support,  nor  Fight  in  this  new  world 
without  major  advances  in  Plug  &  Fight  capabilities 

•  OS  Process  is  no  panacea,  but  enduring  solutions  are  unlikely  without  it 

•  We  find  no  viable  or  practical  alternative 


OS  Process  is  critical  to 
future  warfighting  and  Title  10  responsibilities 
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Pilot  Open  Systems  Efforts 
Have  Produced  Impressive  Results 

•  Army  Intelligence  and  Electronic  Warfare  Common  Sensor  (IEWCS) 

-  Interchangeable  and  interoperable  common  modules;  VME  interface  standards 

-  Replaced  six  legacy  systems;  increased  interoperability;  reduced  development  &  production 
costs  by  40%,  R&D  time  by  64%,  EMD  time  by  29% 

-  Navy’s  New  Attack  Submarine  (NSSN) 

-  OS  Architecture  implemented  through  an  OS  IPT  &  Modular  Design 

-  2:1  reduction  in  development  time 

-  Greater  than  5 : 1  reduction  in  development  costs 

-  4:1  reduction  in  procurement  cost 

•  F-15,  F/A-18,  AV-8B  common  processor  pilot  programs 

-  Cross-program  modular  HW  &  SW  interfacing  with  legacy  platform  and  subsystems 

-  Expecting  about  50%  improvement  in  development  and  O&M  costs 

•  Seventh  Fleet  Command  Ship  (USS  Blue  Ridge) 

-  Converted  Mission  and  Housekeeping  functions  using  OS  Process  and  COTS 

-  Modified  ship  structure  to  enable  open,  rapid  reconfiguration 
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Pilot  Open  Systems  Efforts  Have  Produced  Impressive  Results 

-  Notes  (cont.)  - 
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An  Open  Systems  Process 
Tailored  for  DoD 
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The  Vision 


Enabling  DoD  to  affordably  configure  and 
integrate  Forces,  systems,  and  processes  for 
high  combat  effectiveness  and  life-long  viability 
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A  Tailored  Open  Systems  Process  for  DoD 


Topics 

•  Critical  OS  Lessons  Learned 

•  Maintaining  System  Viability  Throughout  Desired  Lifetime 

•  Architecture-Driven  Modularity 

•  Administering  an  Open  Architecture 

•  Standards  and  Openness 

•  Risk  of  Adopting  an  OS  Process 

•  Managing  to  Enable  Natural  Cycle  Rates 

•  Configuring  Systems  for  High  Cycle  Rates 


OS  Process  is  the  principal  foundation  for 
achieving  Plug  &  Fight/Play  and  COTS  economies 
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Critical  Open  Systems  Lessons  Learned  for  DoD 


The  Nuggets 

(1)  Configure  Forces,  systems  and  processes  for  continuous  viability 

(2)  Achieve  architecture-driven  modularity 

(3)  Manage  to  the  natural  cycle  rates  of  underlying  components 


•  U.S.  Forces,  systems,  and  processes  severely  threatened  by  their  lack  of  agility  in  dynamic  world 

•  For  systems,  today’s  threat  domains  include  not  only  combat  capability  but  also  inadequate 
affordability,  response  time,  sustainment,  eroding  supplier  base 

Must  configure  for  constant  evolution  in  a  dynamic  world 

•  Our  Forces  and  systems  must  be  rich  in  “smart”  modularity,  driven  by  architecture,  and  configured 
as  a  hierarchy  of  modular  “sockets”  enabling  adaptation  in  a  dynamic  world 

•  Must  revamp  our  management  processes  to  encourage  and  leverage  the  natural  cycle  rates  of  the 
underlying  components 


The  primary  benefit  of  the  OS  experience  for  DoD 
is  not  so  much  about  mandating  pure  “Open”  solutions  as  it  is  about 
extensive,  wise  modularity  and  a  significantly  enlightened  management  approach 
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Analyzing  and  Addressing  Viability  Risk 

-  A  Strawman  Approach  - 

The  fact  of  program-threatening  evolution  is  absolutely  certain  — 

Need  to  develop  explicit  risk  mitigation  strategies 

Step  1:  Risk  Analysis:  Characterize  expected  evolution  and  cycle-rate  of  the  key  factors 
affecting  viability  throughout  the  life  of  the  product 

-  Likely  topics  include:  affordability,  technology,  subsystem  characteristics,  external  interfaces, 
requirements,  supplier  base 

-  (Attributes  for  life-long  viability  probably  needed  just  to  get  through  EMD  —  witness  F-22) 

Step  2:  Apply  Plug  &  Fight/Plug  &  Play/Openness  as  critical  attributes 

-  Example  program  tasks:  concept  development,  analysis  of  alternative,  acquisition  strategy, 
tailored  program  management  scheme 

-  Example  OS  topics:  continuing  affordability,  evolving  connectivity,  tech  refresh,  suppliers 

Step  3:  Demonstrate  that  architecture  gets  best  life-long  viability  within  available 
resources 

Step  4:  Include  OS  Process  in  all  relevant  procurement  matters 

-  e.g.,  Requirements,  specifications,  Source  Selection  Criteria ,  etc. 

Make  sound  life-long  viability  a  mandatory  milestone  review  item 


19  OCT  98 


26 


Architecture  Driven  Modularity 


Capturing  the  benefits  of  Plug  &  Fight,  Plug  &  Play ,  and  Commercial  OS 

requires  a  hierarchy  of  architectures 
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Axioms 

•  Plug  &  Fight,  Plug  &  Play,  and  Open  components  are  related  but  different 

•  Each  must  be  individually  nurtured,  but  in  a  coordinated,  mutually  supportive  approach 

•  Each  must  impose  only  the  minimum  essential  requirements,  or  they  will  stifle  the  others 

•  Ops,  Tech,  and  Sys  Architectures  each  have  different  sponsors,  as  does  each  tier  of  the  hierarchy 

•  Forces  and  systems  must  be  simultaneously  compatible  with  all  relevant  architectures  in  the  hierarchy 
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Hierarchy  of  Modular  Architectures 

-  Notes  (cont.)  - 
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Partitioning  for  Modularity 

Good  modularity  demands  robust  isolation  of  constituent  elements, 
connected  only  through  interoperable  interface  specifications 


Design  attributes: 


-  Modularity 

-  Portability 

-  Scalability 


-  Element  substitution  and  renewal 

-  Reuse  and  resource  sharing 

-  Ready  modernization  and  growth 


How  much? 

-  System-of-systems  needs 

-  Operability  and  interoperability 

-  Commonality  (horizontal,  vertical,  across  functions) 

Decomposing  the  system 


Attributes  often  compete  -  for  example: 

•  MS  Windows  gives  broad  commonality 
but  poor  interoperability  and  reliability 

•  Apple  gives  interoperability  and 
reliability  but  limited  commonality 


-  Emphasize  open  partitioning,  leverage  standards,  get  expert  advice 

-  Need  hard  isolation  of  modules,  interact  only  through  interface  specs 


Implementation 

-  Designated  system-of-systems  and  system  architects 

-  Mechanisms  to  assure  local  decisions  don’t  compromise  system  design 

-  Test  attributes  sought 

-  Tight  discipline  throughout  life  cycle;  don’t  let  attributes  dissipate 
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DoD  Already  Understands  the  Basics 

-  Similar  to  Architecting  for  Software  Development  - 


•  OS  Process  in  DoD  today  is  analogous  to  software  development  20  years  ago 

-  Was  art,  now  art  +  discipline  with  axioms,  institutions  (e.g.  SEI),  and  milestone  exit  criteria 

Very  good  architecting  is  as  essential  for  good  modularity  as  for  SW  development  — 

A  flawed  architecture  compromises  all  that  follows 

•  Key  outputs  are  overall  structure,  partitioning,  and  interface  standards 

•  The  basics  are  at  hand  and  already  understood  —  it’s  mostly  a  matter  of  doing  it 

•  Systems  architecting  is  a  discipline  of  balancing  dissimilar  requirements  such  as  CONOPS, 
schedule,  performance,  risk,  supportability,  reliability,  and  cost,  according  to  the  customer’s 
relative  priorities 

•  Only  one  or  two  attributes  usually  can  be  constrained,  but  good  architecture  optimizes  the  mix 

•  The  architecture  needs  to  follow  Open  principles,  even  if  the  parts  are  less  than  Open 

•  But  even  if  parts  not  Open,  must  follow  the  OS  Process  tenants,  or  product  will  almost  certainly  be 
monstrous  to  employ  and  sustain 


Axiom 

Architecture-driven  modularity  is  requisite  to  achieving  OS  attributes  — 
therefore,  OS  Process  should  be  a  mandatory  and  non-negotiable  discipline 
for  all  activities  configuring  Forces,  systems,  and  processes 
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Developing  and  Sustaining  a  Hierarchy  of  Architectures 

-  Some  Institutional  Imperatives  - 


•  We  have  all  been  scared  by  blanket  imposition  of  well-intended  causes  de  jour 

•  While  desired  outcomes  and  constraints  can  be  mandated,  detailed  solutions  should  be 
collaborative  amongst  the  stakeholders  (and  be  prepared  to  motivate  intransigent 
stakeholder.) 

•  Achieving  a  widespread  DoD  OS  Process  will  require  aggressive  championing,  but 
anointed  “do  it  my  way”  czars  will  be  successfully  resisted  at  all  levels 

•  Through  Acquisition  Reform,  DoD  digging  out  from  under  the  regulatory  heap  that 
was  burying  it 

•  Need  for  OS  Process  become  a  mindset  and  core  value ,  not  another  massive 

bureaucracy _ 

Axioms 

•  Only  the  vital,  bare  minimum  constraints  needed  to  do  the  job  should  be 
imposed,  and  at  the  highest  functional  and  organizational  tiers  practical 

•  Our  performance-based  acquisition  should  also  be  our  OS  Process: 

-  Higher  tiers  identify  needed  outcomes  and  assure  high  integrity  processes 

-  Stakeholders  in  the  solution  devise  the  how 


19  OCT  98 


31 


Administering  an  OS  Architecture 

-  Generic  OS  Process  Model  - 


Requirements  and 
Resources 


Requirements  and 
Direction 


Recommendations  and 
Signoffs 


Require 

Direction, 


ncnts  > 
Funding 

Repo 


ting 


Desiree  Outcome  Recomntended  Advice  i 

>  1  Architecture  &  Changes 


OS  Prjocess 

Reporting,  Desired  b  utcome 
Waiters 


Collaboratively 

i  r 

i 

! 

|  : 

Defined 

i— 

i 

Architectures 

^  Participants 

^  i 

Recommended 
Standards 


&  Changes 

<- 


Collaboratively 

Established 

Standards 


System  Architect 
(Systems  Engineering) 


Stakeholders 


Participants 


System  Level 
E.  g.,  Operators, 
Acquirers, 
Sustainers, 
Industry 


Detailed 
Implementation 
E.g.,  Acquirers, 
Sustainers, 
Industry 


19  OCT  98 


32 


Administering  an  OS  Architecture:  Generic  OS  Process 

Model 

-  Notes  (cont.)  - 
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Force  Level  Interoperability 

-  An  OSD/JCS  System-of-Systems  Application  - 
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Single  Integrated  Air  Picture 

-  An  Emerging  Joint  System-of-Systems  Application  - 


Service  Performance 
Needs:  Commonality 
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Weapons  System  Level  Application 


System  Sustainment  Needs:  Growth, 
Manage  Parts  Obsolescence,  Tech  Refresh 


Major 

System 


Prime  KTR 


A 


System  Architect 
Systems  Engineering 


i 


Stakeholders 

Operators,  Acquirers 
Sustainers,  Industry 

Acquirers,  Sustainers, 
Industry 

Subsys  Architect 
Systems  Engineering 

. . ■■■ 

_ Stakeholders 

Operators,  Acquirers 
Sustainers,  Industry 

Acquirers,  Sustainers, 
■  Industry _ 


Subsystem 

Components 


Sub/Supplier  CCB 


Component 

- 1  i 

^  | 

Operators,  Acquirers 

Migration 

Sustainers,  Industry 

1  : 

Standards 

Acquirers,  Sustainers, 

Industry 

Systems  Engineering 


A. 


19  OCT  98 


36 


Standards  and  “Openness” 


•  Standards  define  the  inter-module  connections  (“sockets”)  which  enable  modularity 

•  “Open”  refers  to  use  of  interfaces  and  protocols  that  conform  to  well  defined,  widely  used, 
preferably  non-proprietary  standards.  Open  standards  are  those  developed  by  recognized  standards 
bodies  or  the  commercial  marketplace.  Standards  may  be: 

•  open  (or  public):  e.g.  tires,  electric  outlets,  some  GPS  data  formats 

-  owned:  e.g.  most  car  parts,  MS  Windows  95 

-  de  facto:  e.g.  8.5”  x  1 1”  paper,  typewriter  keyboard 

-  proprietary:  e.g.  most  weapons  systems  key  components 

•  The  level  of  Openness  refers  to  the  system  design  level  at  or  above  which  interfaces  conform  to 
Open  standards 

•  The  level  of  Openness  determines  the  extent  to  which  a  weapon  system  can: 

-  Use  multiple  suppliers  for  competitive  procurements  through  its  total  life  cycle 

-  Insert  new  hardware  and  software  technology  whenever  available 

-  Assign  the  control  of  design,  repair,  and  replacement  to  the  supplier 

•  An  “80%”  quick,  Open  solution  which  is  affordable  and  sustainable  is  usually  better  than  a 
functionally  ideal  solution  which  we  probably  can  neither  afford  nor  sustain 


Axiom 

Strong  presumption  for  the  “most  Open”  solution 
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Sometimes  “Less  Open”  is  the  Best  Answer 

-  But  the  Burden  of  Proof  Should  be  Rigorous  - 


•  OS  Process  presumes  “most  Open,”  but  that  is  not  always  feasible;  less  Open 
is  sometimes  desirable  in  upgrades  of  legacy  systems  with  limited  remaining 
lifetimes  where  adoption  of  Open  standards  is  not  economically  feasible 

•  Less  Open  often  applies  when: 

-  Easiest  subsystem  or  component  changes,  upgrades,  or  replacement  are  not 
needed 

-  Cost  effective  insertion  of  rapidly  advancing  technology  is  not  required  during 
remaining  life  cycle 

-  Cost  reduction  through  competition  is  neither  viable  nor  economically  desirable 

•  Sometimes  less  Open  solutions  really  do  enable  better  CONOPS, 
supportability,  functionality,  and  even  total  life  cycle  costs 
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Choosing  Standards 


•  Criteria  (some  may  be  in  conflict  —  requires  engineering  and  business  judgment): 

-  Consistency  with  the  architecture 

-  Does  it  work  well  in  this  application? 

-  Degree  of  Openness,  breadth  of  use,  and  continued  support 

-  Robust  capability  for  future  evolution  of  system  throughout  life  cycle 

-  Extent  of  Plug  &  Fight  (ex:  coalition  warfare  - >  commercial  standards) 

•  Increased  care  must  be  used  when: 

-  A  standard  has  not  matured  (e.g.,  CORBA) 

-  Proprietary  extensions  necessary  for  performance  requirements 

-  Multiple  standards  exist  for  the  same  function 

-  A  standard  does  not  exist  and  new  work  needs  to  be  reusable 

-  Avoid  hollow  standards! 

“Practical  Open ”  =  Widely  used  and  supported,  as  Open  as  practical 
(wide  use  outweighs  Openness) 
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Choosing  Standards 

-  Notes  (corn.)  - 
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Risks 


Risks  associated  with  “more  Open”  options  include: 


-  Budget  and  Service  investment  philosophy: 

•  Upfront  $$  required  for  OS  Process  systems  engineering 

-  Backward  compatibility  within  legacy  systems  can  be  expensive 

-  Need  to  sway  industry  standards  bodies;  requires  early  proactive  involvement 

-  Industry  concerns  over  proprietary  data  and  investment  for  competitiveness 

-  Availability  of  standards,  their  evolution  &  obsolescence 


-  Market  acceptance  of  emerging  standards  not  assured;  need  backup  plans 

•  But,  taking  a  chance  and  guessing  wrong  is  still  “cheaper,  faster,  better”  than 
developing  a  DoD-unique  solution 

Enabling  future  reuse  requires  additional  $$,  offset  by  reducing  recurring  test  $$  — 
ex:  recurring  SW  regression  testing  costs  DoD  $B/year 


-  Numerous  methodologies  and  technical  challenges,  but  within  our  grasp 

Even  with  all  this,  US.  government  process  impediments  are  the  single  greatest 
risk 


Risks  are  real,  but  are  dwarfed  by  the  benefits; 
Up-front  funding  a  major  problem 
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Risks 

-  Notes  (cont.)  - 
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Managing  to  Natural  Cycle  Rates 

-  Parsing  Systems  by  Natural  Cycle  Rates  - 


•  Mildly  constrained 

ex.  Command  Post,  including  airborne  &  mobile;  shipboard  and  sub  electronics 

-  Rack  typically  isolates  boards  from  platform  environment 

-  Adequate  weight,  space,  power,  cooling;  rack  interconnects  flexible 

-  High  leverage  of  commercial  technical  and  business  practice 

•  Severely  constrained 

ex.  tactical  missiles 

-  Some  commercial  components  but  not  boards 

•  Tightly  constrained 

ex.  Tactical  aircraft  avionics 

-  Enclosure  can  isolate  boards  from  platform  environment 

-  Tightly  constrained  weight,  space,  power,  cooling 

-  Enclosure  interconnects  inflexible 

-  Can  achieve  many  commercial  advantages,  but  need  new  approaches 
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The  March  of  Technology  Ought  to  be  Saving  Programs 

-  Managing  to  Let  It  Happen  - 


Late  ‘80s 

8  boxes 
9ft3 

capability  xl 
$2M 


March  of  Technology —  Radar  Processor  example 


ex:  Industry  Radar  Signal  Processing  Projections 

Early  ‘90s  Today  -2000 

2  boxes  2  boxes  1  box 

3ft3  2ft3  lft3 

capability  x2  capability  x4  capability  x6 

$1M  $0.5M  $0.3M 


-2005 

0.5  box 
.5ft3 

capability  xlO 
$0.1M 


Concept  Def 


Typical  System  Acquisition  Timeline 
Development  Test  ' 


LRIP 


Production 


Think  of  systems  and  processes  as  the  means  to  harness  change: 
Encourage  natural  cycle  rates ,  synchronizing  at  key  milestones 


Low  Cycle  Rate 
Medium  Cycle  Rate 
High  Cycle  Rate 
Program  Schedule 


ex:  Basic  Structure  (20+  yrs) 


ex:  Basic  Architecture 


elements!  (backplanes,  t  nclos  ires,  en  t’ines )  (10 


ex:  Digital  Electronics 
CPU  1  »  CPU  2 


Design 


(18-36irips) 
CPU  3 


*  Fab 


CPL 


CPU 


Qual  I :  Eval 


RIP 


15yrs) 


C  >U6 


CPU  7 


Production 


CPU  8 


Deployment 


Synchronization  Milestones 


Mod  when 
inescapable 


Mod  when 
optimal 
(2-5  yrs) 


•  Cycling  continues  throughout  the  entire  life  of  the  program;  PM  responsible  for  full  life 

•  Measures  needed  for  sustainment  also  needed  for  EMD 

•  Controls  configuration  with  architecture  and  F3I  “sockets”,  not  at  piece/part  level 

•  OS  architecture  enables  concepts  such  as  Spiral  Development  and  Evolutionary  Acquisition 
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The  March  of  Technology  Ought  to  be  Saving  Programs 

-  Managing  to  Let  It  Happen/Notes  (cont.)  - 
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Product  Configurations  to  Enable  High  Cycle  Rates 

-  Decoupling  System  Elements  - 

TACAIR  avionics  —  a  stress  case  and  major  investment  cost 


SOFTWARE 

Common 

Software 

Architecture 


HARDWARE 


Airframe  Raciar  Tgts  FUR  Wpns 


Resource  Controller 
Operating  System 
Board  Support  Package 
Hardware  (CPU,  Memory,  I/O) 


System  Elements  Decoupled: 

Software 


Architecture,  language,  and 
operating  system  provide 
medium  cycle -rate  stability 


Application  and 
HW  host  cycle 
at  natural  rates 


AIRCRAFT  PORTION 

(racks,  cables,  connectors) 

•  Inflexibility,  poor  reliability 

•  Massive  upgrade  cost 

•  Stifles  currency 


PLUG  &  PLAY  AVIONICS  ENCLOSURES 

High-performance  board  F3I,  backplane 

Robust  connections  to  cockpit  and 
outboard  equipment  bays 

Avoids  many  aircraft- side  failures  and 
upgrade  $$$ 

Subsystem  evolution  addressed  at  board  level 


Arch,  language,  op  sys, 
Applications,  (processor) 


Cycle  Rate 

Low  (20-30  yrs) 
Medium  (10-15  yrs) 
High  (3-5  yrs) 


Hardware 

Air  Frame 
Enclosures,  cabling 
Board  components 
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Configuring  Systems  for  High- Cycle-Rates  Components 


•  High  cycle-rate  items  are  mostly  electronics 

•  Most  DoD  electronics  can  be  readily  configured  for  good  commercial  OS  Processes 

-  Isolating  commercial  elements  from  platform  environment  preferable  to  MILSPEC  hardening  (ex:  already 
have  commercial  boards  on  tactical  vehicles,  surveillance  aircraft,  subs) 

-  Permits  frequent  technology  refresh  to  preserve  suppliers,  relieve  problems,  reduce  costs 

-  Need  good  F3I  at  enclosure  and  board  level 

-  Well  partitioned  functions  enable  asynchronous  evolution,  modernization  through  spares 

-  Subsystems  can  even  be  rearchitected  (ex.  repartitioning  signal  and  data  processing) 

-  Suppliers  can  refresh  boards  as  needed;  minimum  platform  and  subsystem  impact 

-  Commercial  standards  —  offer  most  benefits,  but  works  even  when  unique  (ex.  tac  missiles) 

•  Apply  philosophy  on  a  broad  scale  in  other  domains  (ex.  electro-mechanical,  power  supplies) 


Axiom 

Manage  enclosures  as  F3I  sockets,  not  as  frozen  configuration  items; 
Let  board  configurations  cycle  as  needed  within  the  F3I  standard 
to  accommodate  rearchitecting  and  high  cycle-rate  components 
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Status 

The  OS  Process  Concept  is  New  — 
How  Close  is  DoD? 
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Open  Systems  Process  Status 

-  Force  Level  - 

Forces  have  embraced  OS  attributes  only  in  very  narrow  areas 

(ex:  some  C4ISR  interoperability ) 

Not  embraced  as  a  broad  enabler .  even  in  areas  of  seemingly  equal  importance 

(ex:  interoperability  of  logistics  management  processes ) 

•  OS  Process  for  JV2010 

-  Impelling  grass  root  initiatives  (ex.  Pacific  Fleet  Command  ships) 

-  Do  not  see  substantive  funding  of  real  projects  within  U.S.,  nor  within  allies  and  coalition  partners 

•  Joint  planning,  deployment,  battle  management,  engagement,  sustainment 

•  Time  to  first  significant  FTX  longer  than  WW  II 

-  Joint  capabilities  accepted  at  personal  level,  but  don’t  compete  in  Service  budgets 

•  OS  Process  in  general 

-  Not  cornerstone  of  vision  for  long-range  viability  and  effectiveness 

•  Minimal  requirements,  plans,  investment,  metrics,  training,  etc. 

-  Minimal  Service  commitment;  not  seen  as  high-leverage  solution 

•  Perceived  very  narrowly  —  fix  specific  problems;  minimum  initial  cost,  performance 

•  Weak  follow-through  on  current  policies  and  directives;  few  penalties  for  non- 
compliance 

•  Services  activities  are  generally  unique  (Title  10  prerogatives) 
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Open  Systems  Process  Status 

-  Force  Level  (cont.)  - 


Little  management  attention  to  exploiting  OS  to  meet  challenges 

-  Few  plans  (OS  Process  not  internalized  or  incorporated  into  daily  processes) 

-  Few  metrics  (no  means  to  evaluate  cost  savings) 

-  Little  training 

-  Little  investment 

-  Inadequate  follow  through  on  current  policies  and  directives 

-  Few  penalties  for  non-compliance 

The  Services  are  not  currently  committed  to  OS 


•Acceptance  of  OS  is  through  Commitment 

-  Active  leadership 

-  Emphasis  on  people  and  training 

-  Participation  in  standards  organizations 


Open  Systems  Process  Status 

-  Acquisition  and  Support  - 


•  Potential  is  staggering;  exciting  initiatives  underway 

-  OS-JTF  &  DARPA  pilot  programs,  Joint  Aero  Commanders’  Group  F3I 

-  Cross-system  work  (F-15//F/A-18//AV-8B;  Sub  Combat  System) 

•  But  generally,  DoD  doing  poorly 

-  Not  yet  truly  embraced  by  Services  or  most  Program  Offices 

-  Don’t  yet  have  a  unifying  concept;  hampers  institutionalizing  process 

-  Hobbled  by 

•  Inadequate  appreciation  of  the  benefits  of  an  OS  Process 

•  Poor  plans,  processes,  training,  funding  flexibility,  metrics,  compliance  with  policies  &  directives 

•  Rigid  statutes,  policies,  bureaucracy 

•  Inadequate  top-down  emphasis  and  structured  incentives 

-  The  fundamental  problems  are  common  across  new  and  legacy  systems  alike 

-  Legacy  systems  and  sustainment  are  particularly  disadvantaged 

•  Crippled  by  old  architectures 

•  Legacy  upgrades  compete  poorly  in  current  budget  crunch 

•  Absence  $$$,  little  progress  likely 

OS  could  have  massive  benefits,  but  OS  Process  has  not  really  arrived; 

Our  management  processes  are  crippling,  self-inflicted  barriers 
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Open  Systems  Process  Status 

-  Acquisition  and  Support  (cont.)  - 
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Revamping  Program  Management 

and 

Oversight  Processes 
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Revamping  Processes  and  Tools 


The  reengineering  of  DoD  processes  and  tools  is  itself  a  systems  engineering  task  — 
Need  an  integrated  approach  to  the  whole  program  management  and  oversight  process 

•  Mindset  and  Core  Values,  Behavior 

•  Requirements 

•  Program  Management 

•  Specifications  and  Contracting 

•  Test  and  Evaluation 

•  Funding 


Need  to  cover  all  elements  of  the  system  life  cycle 
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Revamping  the  Management  and  Oversight  Process 

-  Changing  the  Way  We  Think  and  Do  Business  - 


•  Traditional  Program  Manager’s  mantra:  Change  is  an  enemy 

“Baseline  to  point  solutions;  shoot  anyone  who  wants  to  change  anything” 


•  Static  solutions  to  dynamic  world 

-  Freeze  and  develop, 

-  Freeze  and  test, 

-  Freeze  and  produce 


•  Traditional  way  doesn’t  work  any  more  ...  the  world  /s  change 


The  process  conflict  arises  from  greatly  shortened  technology  cycle  times 
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Requirements 

-  Demanding  OS  Attributes  as  Mission  Critical  - 


•  When  challenging  dead  end  architectures  and  technologies,  a  frequent  reply  is:  .  .under 
intense  scrutiny,  absolute  requirement  to  minimize  cost  and  risk” 

•  Severely  disincentivizes  investment  beyond  the  minimum  immediate  need  —  all  potential 
outcomes  for  Program  Manager  are  downside,  little  upside  reward: 

-  “We  have  dead-end,  stovepipe  systems  because  we  disincent  anything  more” 

-  The  most  powerful  incentive  for  the  OS  Process  is  to  correct  the  disincentives 

•  Requirements  need  to  demand: 

-  Plug  &  Fight/Play  in  favor  of  the  last  increment  of  individual  performance 

-  Configurations  which  will  be  viable  in  the  long  run,  staying  abreast  of: 

•  Evolving  force  and  operational  needs 

•  Realities  of  budget,  technology,  and  supplier  availability 

-  Robust  migration  path 

•  Facilitate  reuse  of  new  work  by  others  (documentation,  transfer  assistance,  etc.) 


Requirements  need  to  demand: 

-  OS  Process  attributes  of  Plug  &  Fight/Play  and  COTS  affordability 

-  System  configurations  and  robust  migration  plans  for  life  long  viability 
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Core  Mindset  for  Program  Management 

-  OS  Process  Must  Permeate  Whole  Structure  - 

•  At  the  Program  level,  OS  Process  will  become  a  survival  core  value 

•  System  solutions  start  with  understanding  the  problem  to  be  solved 

-  System  definition  phase  must  include  a  Viability  Risk  Analysis  and  required  interfaces  with  related 
architectures 

-  OS-compatible  analysis  tools  should  be  accessed  —  partitioning,  cost,  technology  and  obsolescence 
projection,  etc. 

•  Architecture- driven  modularity  developed  in  system  engineering  process  enables  Plug  &  Play 
HW  and  SW,  and  reuse  —  minimizes  constant  regression  testing 

•  OS  Process  attributes  and  robust  migration  plans  demonstrated  in  System  Concept  Definition 
and  intergrated  into  Performance  Specifications 

•  Management  processes  nurture  natural  cycle  rates  of  components  and  interfaces 

•  Enabling  Program  Management  infrastructure  also  demonstrated;  for  example: 

-  Acquisition  plan,  review  processes,  and  criteria 

-  Architectural  Control  Board  (ACB)  and  compliant  architecture  hierarchy 

-  Contracting  and  Source  Selection  criteria 

-  Test,  product  support,  training 

-  Diminishing  supplier  program 

Must  permeate  entire  acquisition  management  processes, 

Source  Selection  criteria,  and  milestone  and  upgrade  reviews 
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Core  Mindset  for  Program  Management 

-  OS  Process  Must  Permeate  Whole  Structure/Notes  (cont.)  - 
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Contracting  and  Source  Selection 

-  Encourage  OS  Processes  - 


Revamp  the  FAR 

-  Natural  extension  of  Performance  Based  Business  Environment  (PBBE)  already  started 

-  Eliminate  regulated  obstacles  to  OS  Process 

-  Impose  architectural  hierarchy  and  ACBs 

-  Align  contract  structure  with  system  architecture  (development  through  support) 

-  Make  OS  Process  a  required  Source  Selection  Criteria 

Reorient  Specifications  and  Interface  Control  Documents 

-  Specify  and  baseline  system-level  functionality  (PBBE)  and  F3I  (OS)  interface  control 

-  Manage  high  cycle-rate  functions  to  F3I  and  mitigation  plans 

•  Contractors  and  suppliers  have  lower  tier  configuration  control  within  F3I  discipline 

•  Abandon  build-to-print  process  in  favor  of  interface  specifications 

•  Contractors  analyze  best  use  of  resources  across  all  criteria 

-  Implement  program  and  migration  plans  by  most  economical  process 

-  Focus  on  best  system/component/part  value 

-  Freedom  to  innovate  using  competitive  pricing 

•  Minimizes  Class  I  changes 

Strong  OS  Process  treatment  in  Source  Selection 


Force  OS  Process  to  become  an  industrial  base  core  competency 


Test  and  Evaluation 

-  New  Philosophy:  Validate  Functional  Performance  and  F3I  Provisions  - 

Many  interviewees  consider  current  test  practice  a  crippling  OS  Process  impediment 

•  Test  philosophy  must  acknowledge  that  configurations  are  temporal  —  they  cannot  pre¬ 
exist  or  endure 

-  IOC  configuration  cannot  pre-exist  at  OPEVAL 

-  OPEVAL  configuration  cannot  pre-exist  at  qual  test 

-  Configurations  probably  not  even  constant  across  test  units 

-  Product  support  must  deal  with  continually  evolving  configurations 

•  Early  functional  testing  may  have  to  use  surrogate  hosts 

•  Must  reengineer  test  flow  to  test  functionality,  F3I,  and  migration  path  early, 
then  balance  other  test  needs  with  reality  of  evolving  product  configurations 

•  Avoid  full  duplication  of  tests  between  configurations,  contractor,  government 

(ex.  Software  regression  testing  is  usually  very  expensive  and  often  unnecessarily  duplicative) 

•  Testing  must  be  tailored  to  the  phase  of  evolution  of  the  product  requirements 


Must  revamp  test  objectives,  philosophy,  criteria; 
Need  demonstration  programs 
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Funding 

-  Current  Practice  Causing  Serious  Difficulties  - 


•  Maintaining  system  viability  requires  overall  life  cycle  Responsibility,  Authorities,  and 
Accountabilities  (RAA) 

-  PMs  generally  have  life  cycle  responsibilities,  but  neither  authorities  nor  resources 

-  Let  PMs  balance  the  pain  between  NRE  and  recurring  O&M 

-  Assign  PM’ s  total  life  cycle  RAA 


Colors-of-Money  (RDT&E  vs.  Production  vs.  O&S)  inhibit  effective  technology  renewal 

-  For  high-cycle-rate  elements,  problems  and  their  solutions  extend  across  color  boundaries 

-  Support  problems  just  as  bad  in  R&D  and  Production  phases 

-  Need  relief  to  allow  technology  renewal  with  any  color-  of-  $$  available 


Current  Practice 
Major  drop  in  capability 
Large  mods  hard  to  fund 


Open  Systems  Process 

Retain  capability 
Changes  easier  to  fund 
Some  don’t  require  govt  $$ 


Funding  need  changes  are  very  difficult  for  most  programs 

-  Changes  mostly  accumulate  until  major  system  upgrades;  often  involve  expensive  platform  mod 

-  Changes  plus  mod  cost  difficult  to  fund;  jeopardizes  program 

-  OS  Process  could  spread  changes,  avoid  many  mods;  funding  more  likely 
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Funding 

-  OS  Process  Can  Improve  the  Situation/Notes  (cont.)  - 
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Infrastructure  Needs 


Tools  for  program  planning,  cost  modeling,  budgeting,  sustainment 

-  Planning  tools  incorporating  high  cycle  effects  and  OS  effects  are  immature 

-  Couldn’t  find  cost  estimating  tools  —  some  being  started 

Acquisition  processes  need  to  be  reengineered  from  PDRR  through  Support 

-  Strong  disciplined  systems  engineering  essential;  grow  competency  by  multiples 

-  Decrease  component  design  and  test  engineering 

-  Develop  management  and  integration  techniques  to  marry  low  cycle  change  elements  with 
high  cycle  change  elements  later  in  process 

-  Confirm  HW  &  SW  structure  very  early  —  before  application  development 

-  New  functional  validation  and  design  review  exit  criteria 

-  Test  philosophy:  Minimize  duplication,  qualify  SW  early,  qualify  HW  late,  update  SW 
always 

Currently  training  is  very  limited 

-  Not  a  curriculum  topic  in  DoD  professional  schools 

-  Acquisition  and  logistics  workforce  not  trained  to  PBBE  and  OS  Process 

-  Functional  and  interface  discipline  vs.  “how-to”  and  “build-to -print’ ’  specs 


Industrial  Base 

DoD-centric  analysis  argues  strongly  for  imposing  extensive  OS  requirements  — 

need  to  consider  impact  on  industrial  base 

•  Business  basics  require  that  investment  be  recovered  and  profit  made 

•  Impact  of  imposing  OS  requirements  on  industry 

-  OS  greatly  reduces  non-recurring  and  recurring  cost,  which  equals  less  profit/win 

-  Few  new  starts  and  upgrades  =  less  wins 

-  OS  reduces  barrier-to-entry;  harder  to  assure  future  business 

-  Incentive  for  unique  investment  drastically  reduced 

-  Primes  significantly  disincentivized  for  OS  Process  unless  business  is  at  severe  risk 

•  Lower  tiers  greater  than  -75%  systems  cost 

-  Face  primes’  problems  +  primes  vertically  integrating  and  influencing  buy  decisions 

-  Lower  tier  unstable;  caught  between  economics  of  DoD,  primes,  and  commercial 

-  Much  OS  use  in  the  lower  tiers 

•  Pressures  are  driving  DoD  to  become  more  involved  in  the  lower  tiers 


Industry  will  follow  if  necessary,  but  not  their  choice  -- 
Recommend  that  DoD  cause  a  detailed  investigation  of 
lower  tier  market  dynamics  and  economics 
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Industrial  Base 

-  Notes  (cont.)  - 


19  OCT  98 


65 


Pilot  Program  Candidates 

There  are  several  programs  which  would  be  good  candidates  to  be  designated  pilot  programs 
for  pathfinding  implementation  of  an  OS  Process: 

-  National  Missile  Defense 

•  Mission  is  to  achieve  and  maintain  a  deployment  ready  posture  until  a  deployment  decision  is 
made,  with  continuous  rolling  technology  insertion  program 

•  Largely  a  System-of-Systems,  dependent  upon  other,  evolving  systems  not  subordinate  to  the 
program  office;  dependent  upon  an  architecture-driven  modularity  approach;  long-term  viability 
will  be  a  particular  problem 

•  Newly  appointed  Lead  System  Integrator  with  good  OS  perspective  and  implementation 
capabilities;  good  chance  of  OS  Process  success 

•  Theater  Air  and  Missile  Defense 

•  Mission  is  to  establish  and  maintain  interoperability  between  a  host  of  service  surveillance, 
battle  management,  and  weapons  programs  to  achieve  an  integrated  trans-DoD  capability 

•  Almost  entirely  a  System-of-Systems,  dependent  upon  other,  evolving  systems  non- subordinate 
to  the  program  office;  dependent  upon  an  architecture-driven  modularity  approach 

•  Requirements  and  CONOPS  responsibility  rest  with  JTAMDO  and  engineering  with  BMDO. 
Lead  system  engineering  responsibility  for  implementation  not  yet  established.  Excellent 
application  of  OS  Process  early  enough  in  process 

•  Joint  Tactical  Radio 

•  Excellent  front-end  effort  but  no  real  implementation  program  yet;  would  be  an  excellent 
application  of  an  OS  Process  early  enough  in  process 
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Incentives 

and 

Disincentives 


19  OCT  98 


67 


OS  Process  Implementation  Challenges 


Should  Be  Easy  Will  be  Tough 


OS  Process  is  a  mindset  for  architecting 

Our  processes  are  dysfunctional  obstacles 

•  We  already  architect  Forces,  systems,  and 

•  Geared  for  static  programs  in  a  static  world 

processes 

•  “Freeze  &  build” 

•  We  already  use  configuration  control  processes 

•  Phobic  to  managing  change;  ex: 

•  OS  Process  is  just  an  additional  criteria 

•  Budgeting  criteria 

•  There  are  industry  and  DoD  role  models 

•  Acquisition  milestones 

•  Some  programs  motivated  as  survival  issue: 

•  Parts/technology  refresh  $$ 

“cheaper,  better,  faster”  can  save  programs 

•  We  should  be  doing  it  anyhow 

Implementing  OS  Process  is  an  institutional  matter 
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Incentives 


•  We  have  smart  people  who  want  to  do  a  good  job;  we  need  to  ... 

-  Remove  the  impediments  and  disincentives 

-  Set  objectives  and  boundaries 

-  Include  OS  achievement  as  a  specific  job  expectation 

-  Evaluate  commercial  incentive  practices 

-  Reward  OS  successes 

•  High  visibility  recognition  by  Leadership 

-  Tolerate  thoughtful  mistakes 

-  Get  out  of  the  way 


Commit  to  removing  the  impediments,  recognize  successes, 

Get  out  of  the  way 
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Incentives 

-  Notes  (cont.)  - 
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The  Most  Crippling  Impediments 

Most  barriers  are  self-inflicted  and  entrenched 


•  Requirements 

-  We  have  stovepiped  systems  and  dead-end  technologies  because  Requirements  demand 
nothing  more  [ex:  B-2  Defensive  Avionics  8088  Processor  —  meets  requirement] 

-  If  we  want  viable,  enduring  Plug  &  Fight/Play  systems,  then  we  need  to  require  them 

•  System  management  philosophy  —  currently  “freeze  and  build” 

-  Baselining  to  the  wrong  criteria:  frozen  detailed  configurations  vs.  F3I  “sockets” 

•  Continuous  technology  refresh  throughout  entire  life  of  system 

•  Leverage  supplier  evolution  and  “cheaper,  faster,  better” 

-  Management  processes  are  phobic  and  dysfunctional  in  today’s  world 
[ex.  management,  budget,  milestone  criteria,  test,  tools ] 

•  Legislation  and  regulation  [ex:  Firewalling  Dev/IOT&E/Production,  Baseline  Breach  reporting ] 

-  Color-of-money  inflexibility  precludes  much  technology  refresh 

-  IOT&E  criteria:  freezes  rather  than  follows  evolving  functionality  and  evolving  product 
configurations 
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The  Most  Crippling  Impediments  (cont.) 


•  NIH  (“Not  Invented  Here”) 

-  OS  Process  is  vital  for  parochial  Title  10  interest,  but  difficult  to  adapt 

-  OSD  sponsorship  invokes  suspicions,  vulnerabilities,  prerogatives 

-  With  OS  Process,  particularly  easy  to  invoke  usual  excuses: 

•  “We’re  already  doing  that” 

•  “We  don’t  need  to  do  that” 

•  “You  can’t  make  us  do  that  (Title  10)” 

•  Lack  of  intense  motivation  and  vigorous  commitment 

-  This  type  of  change  will  not  naturally  occur  —  requires  aggressive  leadership 

[ex:  AF  infusion  of  reliability  into  T AC  AIR] 

-  Commitment  at  some  lower  DoD  and  industry  levels  for  program  survival 

[ex:  JSF,  IEWCS] 

-  Senior  Leadership  not  there  yet 


OS  Process  can  be  done  and  would  have  massive  benefits, 
but  the  barriers  preclude  its  wide  implementation 
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The  Most  Crippling  Impediments 

-  Notes  (cont.)  - 
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Conclusions  and 
Recommendations 
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Conclusions 


•  Open  Systems  Process  is  fundamental  to  many  DoD  priorities  that  are  dependent  upon  a 
process-based  approach 

-  JV  2010  and  Service  equivalents  -  Reduced  cycle  time  and  ownership  costs 

-  Force  modernization  -  Favorable  industrial  base  realignment 

Open  Systems  Process  is  a  Warfighting  and  Title  10  essential  core  value 

•  Forces,  systems,  and  processes  need  to  leverage  change: 

-  Configure  Forces,  systems  and  processes  for  continuous  viability 

-  Achieve  architecture-driven  modularity 

-  Manage  to  the  natural  cycle  rates  of  underlying  components 

•  Open  Systems  Process  is  based  upon  a  hierarchy  of  architectures  and  standards  developed 
with  a  performance-based  collaborative  approach 

•  Unlikely  that  DoD  can  implement  Open  Systems  Process  by  usual  bureaucratic  means 

-  Open  Systems  Process  is  a  cultural  and  budget  challenge—  process  is  within  our  grasp 

-  Requires  support  from  DoD,  Administration,  Hill,  and  Industry 

-  Need  to  reconfigure  Forces,  systems,  and  management  processes 

-  Removing  impediments  is  most  important 

Requires  aggressive  leadership,  SecDef  and  Service  Secretary  championing 
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Conclusions 

-  Notes  (cont.)  - 
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Recommendations 


( 1 )  Establish  Special  Assistant  for  OS  Process 
Implementation 

(2)  Take  Immediate  Program  Actions 

-  Direct  preliminary  efforts 

-  Designate  pilot  programs 

(3)  Institutionalize  OS  Process 

-  Implement  and  mandate  Open  Architectures 

-  Revamp  management  processes 

(4)  Leadership  and  Championing 
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Recommendations 

-  Establish  Special  Assistant  for  OS  Process  Implementation  - 

Appoint  a  Special  Assistant  for  OS  Process  Implementation  within  immediate  office  of  the 

SecDef 

•  Focus  on  permeating  the  process ,  not  individual  solutions 

•  Normal  DoD  mechanisms  inadequate  to  broadly  and  effectively  implement  an  OS  Process 

(ex.  existing  OSD  Executive,  Steering  Group,  Agency,  Lead  Service,  etc.) 

-  Precluded  by  inexperience  and  organizational  impediments,  equities,  prerogatives 

•  Effective  implementation  requires  empowered  advocate,  solid  OS  Process  experience 

-  Provocateur,  advocate,  guide,  expert  counsel,  mentor 

-  Map  general  implementation  path,  recommend  actions  and  direction 

-  Executive  advisor  to  SecDef,  CJCS,  and  staffs 

-  Implementation  secretariat,  staffed  by  OSD  Open  Systems  Joint  Task  Force 

•  Appointing  a  Special  Assistant  to  the  SecDef  is  markedly  superior  to  normal  mechanisms 

-  Ensures  someone  with  considerable  industry  and  DoD  experience 

-  Probably  no  single  individual  with  all  the  desired  experience  and  stature,  but  can  get  close 
enough  to  jumpstart  the  process 

-  Have  identified  a  sample  candidate  from  industry  (DoD  candidates  lack  sufficient  industry 
experience) 

•  Could  support  with  a  USD(A&T)/VCJCS/ASD(C3I)  OS  Implementation  Board 
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Recommendations 

-  Immediate  Programs  Actions  - 

There  are  some  specific  measures  which  can  and  should  he  taken  immediately 

•  JCS  within  nine  months  amend  all  MNS  and  ORDs  to  require  OS  Process  attributes 

-  Continuing  viability 

-  Architecture-driven  modularity 

-  Configure  and  manage  to  leverage  natural  cycle  rates  of  components 

•  USD(A&T)  within  three  months  direct  all  programs  to 

-  Develop  a  Viability  Risk  Mitigation  Program  and  adapt  a  preliminary  formal  OS  Process 

-  Conduct  a  Viability  Risk  Analysis  and  develop  a  mitigation  strategy  --  compliance  or 
approved  Migration  Plan  within  1  year 

•  Immediately  implement  an  OS  Process  to  develop  architectures,  infuse  architecture- driven 
modularity,  and  capture  OS  attributes 

•  Fully  integrate  OS  Process  results  into  products,  management  processes,  acquisition  actions 

•  Make  OS  per  OS  Process  an  immediate  mandatory  Source  Selection  Criteria 

•  Mandatore  milestone  review  topic  at  all  levels,  fully  compliant  with  approved  migration  plan, 
within  earliest  of  either  two  years  or  two  milestone  reviews 

•  USD(A&T)  immediately  designate  pathfinding  OS  Process  major  programs  (ex:  NMD, 
TAMD,  JTRS,  etc.) 
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Recommendations 

-  Institutionalize  OS  Process  - 

Mandate  &  fully  implement  needed  DoD-wide  interoperability  architectures 
( example  domains:  C4ISR,  weapons  systems,  M&S,  logistics  management  systems,  etc.) 

•  For  each  designated  interoperability  domain,  establish  an  Architecture  Control  Board  and 
supporting  structure  at  OSD/JCS  and  Service  levels,  and  throughout  subordinate  levels 

•  Suggest  an  approach  based  upon  classic  Program  Office  Configuration  Control  Board 

-  Advisory  to  Line  Authorities 

•  Establish  needed  functionality 

•  Establish  adequacy  of  proposed  architectures  and  compliance  with  higher-tier  architectures 

•  Evaluate  proposed  changes 

•  Assure  integrity  of  processes 

•  Establish  and  oversee  compliance  mechanisms 

-  OSD/JCS  Architecture  Control  Board  is  additional  role  of  existing  ACC 

-  Each  board  should  be  supported  by  genuine  architects/system  engineers  acting  in  the  interest 
of  the  Line  Authority  being  advised 
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Recommendations 

-  Institutionalize  OS  Process  (cont.)  - 


•  OSD  and  JCS  immediately  enforce  existing  policies  or  change  them 

•  USD(A&T)  immediately  and  explicitly  attack  each  impediment  identified  by  this  OSTF 
and  the  OS-JTF  survey 

•  New  Special  Assistant  for  OS  Process  Implementation  within  six  months  roadmap  a 
structured  effort  to  (1)  revamp  relevant  management  and  oversight  processes,  (2)  establish 
incentives,  and  (3)  attacking  impediments 

-  Example  domains  for  revamping  :  requirements,  cost  and  budget,  program  management, 
support  processes,  source  selection,  performance  measures,  reporting  and  oversight 

-  Coordinate  closely  with  other  reform  efforts  such  as  Acquisition  Reform  &  RMA 

•  USD(A&T)  and  CJCS  direct  revamping  per  the  roadmap 

-  Include  with  other  special  reform  activities 

-  Develop  end  objectives  and  implementation  plans  within  4  months  of  go-ahead 

-  First  revision  of  all  directed  processes  within  1  year 

•  Immediately  grant  interim  relief  for  programs  to  start  tailoring  legacy  program 
management  processes  for  an  OS  Process 
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Recommendations 

-  Institutionalize  OS  Process  (cont.)  - 


Establish  Task  Force  to  examine  implications  for  industrial  base,  particularly  2nd 
and  3rd  tier  suppliers 

Establish  structured  process  for  early  proactive,  consistent,  and  constructive  DoD 
participation  in  relevant  industry  standards  bodies 

Revise  OS-JTF  role 

-  Continue  current  roles 

-  Become  Secretariat  to  SecDef  Special  Assistant  for  Implementation 

-  Nominate  more  senior  director  with  industry  credentials,  institutional  credibility, 
and  historical  perspective  on  the  challenges 

-  Augment  staff  skill  mix  to  include  warfighter,  program  manager,  engineer, 
logistician,  cost  analysis,  budget,  and  test  experience 

Establish  government/industry  OS  Process  Coordination  and  Advisory  Council 


Recommendations 

-  Leadership  and  Championing  - 

•  DoD  Warfighting  and  Title  10  capabilities  on  downward  spiral 

•  An  Open  Systems  Process  is  requisite  to  many  DoD  priorities 

•  Open  Systems  Process  is  no  panacea,  but  is  a  cornerstone  for  all  solutions,  a  historic  endowment 

•  Implementing  OS  Process  is  an  institutional  issue  —  methodology,  technology  are  manageable 

•  Time  is  of  the  essence  due  to  need  and  change  of  administration. 

•  Such  change  comes  only  with  aggressive  leadership  [ex:  AF  TACAIR] 

Basically  a  binary  choice 

•  Energetic  and  dynamic  SecDef,  JCS,  and  Service  leadership  could  be  decisive 

-  With  it,  there  is  a  chance;  without  it,  broad  implementation  will  not  happen 

•  Would  require  working  with  Mr.  Cohen  and  Mr.  Hamre  to  develop  a  strong  personal  commitment 

•  Equal  commitment  needed  from  remaining  leadership 


Task  Force  recommendations  assume  aggressive  implementation. 

If  DoD  leadership  cannot  commit,  then  merely  issuing  guidance,  including  OS  Process 
in  ongoing  reforms,  and  helping  the  system  do  as  best  it  can  will  not  be  sufficient 
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Recommendations 

-  Leadership  and  Championing  - 


SecDef  within  45  days: 

-  Hold  off-site  with  Chairman,  Service  Secretaries,  Chiefs,  CAEs 

•  Secure  personal  commitments  to  Plug  &  Fight  and  OS  Process 

•  Press  Conference 

-  Shared  commitment  and  Call  for  Action 

-  Announce  action  leadership 

-  Formally  request  Dongressional,  Administration,  and  industry  support 

-  DoD-wide  call  for  identification  of  impediments  to  implementation 

Chairman,  Service  Secretaries,  Chiefs,  CAEs,  Agency  Heads  within  next  30 
days: 


Take  corresponding  actions 


